feat(CLI): Typed rendering for call output by marijamijailovic · Pull Request #2179 · 0xMiden/rust-sdk

marijamijailovic · 2026-05-13T08:42:23Z

This PR extends the call command: miden call now reads the procedure’s types from the package manifest. It prints the signature with type names, takes each argument as a single token of its own type, and prints the result the same way.

$ miden-client call <ACCOUNT_ID>:transfer-to \
    0xa591009a3022e800788f9ed177dcdb \
    100::0xc2c65cc6c0ff4c314b8db7550f8886 \
    56 \
    -p wallet.masp

transfer-to(account-id, asset, felt) -> account-id
account-id(0xa591009a3022e800788f9ed177dcdb)

Argument conventions:

‎felt: ‎56
‎word: ‎0x0100…
‎account-id: ‎0xa591…
‎asset: ‎<AMOUNT>::<FAUCET_ID>

The types come from the WIT signature in the manifest, and the encoding and decoding live in ‎miden-vm, in ‎miden_mast_package::typed. The CLI only adds codecs for ‎account-id and ‎asset, which need protocol rules that the VM doesn’t have.

A procedure exported without a WIT signature still works: its arguments are read as one field element each, and the result is printed as a stack dump.

Closes #2098

marijamijailovic · 2026-05-14T07:20:24Z

Hi @igamigo! Quick question about the changelog for this PR: there is already an entry saying “Added miden-cli call command for invoking account procedures directly from the CLI”. Should we reuse that existing entry for this PR as well, or to add a new changelog entry that explicitly mentions typed rendering for the call output?

igamigo · 2026-05-15T14:43:31Z

Hi @igamigo! Quick question about the changelog for this PR: there is already an entry saying “Added miden-cli call command for invoking account procedures directly from the CLI”. Should we reuse that existing entry for this PR as well, or to add a new changelog entry that explicitly mentions typed rendering for the call output?

I think we can reuse it and add this PR link to the same entry since it's very related, but not a strong opinion so if you prefer otherwise that's fine too.

igamigo · 2026-05-15T14:45:35Z

Can you expand the PR description explaining the design a bit and how it relates to the issue? And/or maybe add some examples of how this renders. I know there is some context there already but the actual implementation and the scope has not been fully discussed AFAICT

marijamijailovic · 2026-05-25T12:10:05Z

Hi @igamigo thanks for your comment! I updated the PR description.

There's one thing I just realized, and because of it I'm turning this into a draft: I accidentally tested it against a compiler branch that isn't merged into next yet, this branch is the one that stores the high-level types inside the debug sections. My bad, I didn't check that my cargo miden build was pointing at my local compiler on that branch instead of the official one from crates. So on packages built with the official compiler the debug sections are there, but it does not saves the functions signature with high level type, and the typed path won't trigger - it'll just fall back to raw.

Keinberger

Approve direction, but let's hold non-draft on the items below. Thanks @marijamijailovic!

Phase 1 from #2098 is covered.

Before flipping to non-draft though:

Test coverage. See inline on package_types/mod.rs — bool, u32, u64 are priority types from #2098 but have no unit test.
Compiler dependency. See inline on tests/cli.rs — the typed path only triggers because the test stubs the debug sections in by hand.
CHANGELOG. The check is still red and I can't drop an inline since CHANGELOG.md isn't in the diff. Per your thread with @igamigo, extending the existing #1943 entry sounds right, something like:

Added miden-cli call command for invoking account procedures directly from the CLI (#1943), with typed argument encoding and typed result rendering when the package carries debug type info (#2179).

Follow-ups to track separately, not here:

Phase 2 SchemaType rendering.
Module naming: package_types reads ambiguous next to the manifest's own FunctionType. Happy to be overruled.

marijamijailovic · 2026-06-01T05:28:00Z

I’ve pushed a follow-up that addresses the review comments on the typed ‎call data:

Added unit tests for ‎bool, ‎u32, and ‎u64, following the same pattern as ‎felt_roundtrip.
Renamed the module from ‎package_types to ‎package_debug_info (and ‎PackageTypesError to ‎PackageDebugInfoError).
Centralized type detection by moving the WIT names into ‎ACCOUNT_ID_TYPE / ‎WORD_TYPE constants with a short comment about the naming assumption, so there is a single place to update once the upstream compiler settles on names.
Updated the CHANGELOG by extending the existing ‎miden-cli call.
Documented in ‎tests/cli.rs that the published compiler does not yet emit typed ‎DebugTypeInfo::Function entries (those are added in compiler#1151, so packages built with the current toolchain still fall back to the raw path.
Switched digest resolution to go through the manifest (export name → digest) instead of ‎package.mast, since ‎mast is marked as unstable and will move from ‎Library to ‎MastForest.
Fixed anonymous-struct handling to use the ‎<anon> sentinel, so they render by field shape (e.g. ‎{x: felt, y: felt}), consistent with what the compiler currently emits and what is described in this comment.
Rust contract functions are usually written in ‎snake_case, but the Miden toolchain exports them as kebab-case (‎take_account_id → ‎take-account-id). To make this friendlier for users, ‎call now treats ‎_ and ‎- as equivalent when resolving procedure names, so both forms work. This also fixed integration tests whose MASM fixture uses bare snake names by normalizing both sides.
‎make clippy currently fails on ‎fs_keystore.rs:232 (‎get_signature) with ‎clippy::unused_async, which seems unrelated to the ‎call changes. I’m happy to fix that in this PR as well if you’d like CI to be green here.

cc @Keinberger @igamigo

marijamijailovic · 2026-06-04T08:17:43Z

cc @BrianSeong99 I am tagging you here so you are aware of this one

marijamijailovic · 2026-06-09T06:35:28Z

Hi @igamigo! Would it make sense to start the review while keeping this PR in draft until the compiler changes land, and then make this one “ready” once the compiler is ready as well?

igamigo

Overall I'm not entirely sure the new package_debug_info should be part of miden_client. It seems like it encompasses a bunch of package/compiler-related helpers and is not really used in the miden-client crate, only the CLI. In this sense, I wonder if it should be placed either in the CLI directly or as a separate compiler crate, as it's very much independent of the codebase here.

marijamijailovic · 2026-06-12T14:30:32Z

Overall I'm not entirely sure the new package_debug_info should be part of miden_client. It seems like it encompasses a bunch of package/compiler-related helpers and is not really used in the miden-client crate, only the CLI. In this sense, I wonder if it should be placed either in the CLI directly or as a separate compiler crate, as it's very much independent of the codebase here.

Thanks, that’s a good point. I agree this probably live inmiden_client long‑term.

I'm thinking about moving the whole typed encoder/decoder into miden-vm/mast-package, under debug_info::typed. The main reason is that the the typed encoder/decoder into ‎mast-package, under ‎debug_info::typed. The main reason is that the encoder/decoder only needs the debug type table (‎DebugTypesSection / ‎DebugTypeInfo), and those types already live in ‎mast-package/src/debug_info/types.rs, so it feels more natural for the typed view to sit next to the data it consumes.

This way the split would be: the compiler writes the debug sections, ‎mast-package owns the debug types and the typed view over them, and client just consume it.

Let me know what do you think? And we can tag in people from the miden-vm / compiler side who can share their opinion.

igamigo · 2026-06-12T20:12:02Z

Hey @marijamijailovic / @Keinberger, just a heads up, if we want this on the 0.15.x we'll need to rebase this to main.

marijamijailovic · 2026-06-18T07:04:01Z

This PR is blocked for now.

miden-client exec and call do not work with the latest compiler on the next branch. We must wait for the fix first.
See: 0xMiden/compiler#1192

After the fix is introduce, I will:

Run full testing locally.
Mark this PR as ready for review.

So this PR stays in draft until then.

marijamijailovic · 2026-06-20T13:52:57Z

Hey @igamigo, rebased on main, miden-vm PR is open — 0xMiden/miden-vm#3276

marijamijailovic · 2026-06-20T13:54:34Z

This PR is blocked for now.

miden-client exec and call do not work with the latest compiler on the next branch. We must wait for the fix first.
See: 0xMiden/compiler#1192

After the fix is introduce, I will:

Run full testing locally.

Mark this PR as ready for review.

So this PR stays in draft until then.

The above issue is resolved.

igamigo · 2026-06-22T14:30:34Z

With the issue resolved are we now ready to move this PR out of draft and have it reviewed? Or were we waiting on the VM patch release?

marijamijailovic · 2026-06-23T09:42:10Z

With the issue resolved are we now ready to move this PR out of draft and have it reviewed? Or were we waiting on the VM patch release?

Thanks for bumping this up! Now that the ‎miden-vm PR is open, my slight preference would be to land the ‎miden-vm patch first so that we can point ‎Cargo.toml at a clean released dependency, and only then move this PR out of draft and mark it ready for review. If you’d prefer to start the review here in parallel with the VM patch, I’m happy to resolve all comments in parallel.

igamigo · 2026-07-22T20:05:13Z

Hi @marijamijailovic, would we be ready to move this PR out of draft or is there anything missing?

marijamijailovic · 2026-07-23T14:17:49Z

Hi @marijamijailovic, would we be ready to move this PR out of draft or is there anything missing?

Hi, not yet, as per comment, I'm now waiting for @bitwalker PR to land first, and then to update how miden call use debug info.

bitwalker · 2026-07-28T13:32:56Z

@marijamijailovic 0.25.8 has landed, and the new debugger has shipped, so I think all the necessary pieces are in place for you now

igamigo

LGTM! Holding off on approving until we have upstream dependencies merged but leaving some mostly minor comments for now.

Also, can you update the PR description? It seems to have gotten stale.

igamigo · 2026-08-05T15:04:30Z

+    #[error("client has not been synced yet")]
+    #[diagnostic(
+        code(cli::not_synced),
+        help("Run `{} sync` first.", client_binary_name().display())
+    )]
+    NotSynced,


igamigo · 2026-08-05T15:06:51Z

 miden-client-sqlite-store = { workspace = true }
 miden-debug               = { optional = true, workspace = true }
+miden-mast-package        = { workspace = true }
+miden-protocol            = { workspace = true }


We should not need this import. AFAIK all types you are using are already being re-exported from miden-client

Thanks, fixed this

igamigo · 2026-08-05T15:09:56Z

+
+    if found_without_signature {
+        return Err(missing_signature(procedure_name));
    }


Previously it seems that such procedures would be callable with u64 args and a stack dump. Is this a regression? If so we might want to add the "breaking" tag to the changelog.

Ah, yes, that was a mistake, thanks for catching it.

I think we should always keep an option to call a procedure even when there’s no wit signature.

igamigo · 2026-08-05T15:12:02Z

+/// Part of the transaction kernel's assertion message for a transaction that changes nothing.
+///
+/// The assertion carries a message rather than a code the executor exposes, so this is matched as
+/// text. It only decides whether an explanatory line is printed: if the kernel ever rewords it,
+/// the line stops appearing and nothing else changes.
+const EMPTY_TRANSACTION_ASSERTION: &str = "neither changed the account state";


I think we should be able to remove this and do something like

let is_empty_transaction = matches!( &e, ClientError::TransactionExecutorError( TransactionExecutorError::TransactionProgramExecutionFailed(exec_err), ) if ERR_EPILOGUE_EXECUTED_TRANSACTION_IS_EMPTY.matches_execution_error(exec_err) );

Which is still not great but at least it does not depend on substring matching against a local const.

Drop the local package_debug_info module and consume the typed encoder/decoder from miden-mast-package's debug_info::typed instead.

…ature

marijamijailovic mentioned this pull request May 15, 2026

Support for remote account #2187

Draft

igamigo changed the title ~~Typed rendering for call output~~ feat(CLI): Typed rendering for call output May 15, 2026

igamigo requested review from Keinberger and igamigo May 15, 2026 14:42

igamigo requested a review from JereSalo May 19, 2026 19:07

marijamijailovic marked this pull request as draft May 25, 2026 12:10

Keinberger reviewed May 27, 2026

View reviewed changes

Comment thread crates/rust-client/src/package_debug_info/mod.rs Outdated

Comment thread bin/miden-cli/tests/cli.rs Outdated

Comment thread crates/rust-client/src/package_types/introspect.rs Outdated

Comment thread crates/rust-client/src/lib.rs Outdated

marijamijailovic force-pushed the pr/call-typed-rendering branch from a74dc47 to 927cc8f Compare May 31, 2026 19:00

igamigo reviewed Jun 11, 2026

View reviewed changes

marijamijailovic force-pushed the pr/call-typed-rendering branch from 5c1cb85 to 69c7a49 Compare June 20, 2026 10:57

marijamijailovic changed the base branch from next to main June 20, 2026 12:40

marijamijailovic mentioned this pull request Jun 20, 2026

Debug info encoder decoder 0xMiden/miden-vm#3276

Open

marijamijailovic force-pushed the pr/call-typed-rendering branch from 69c7a49 to 707e7cd Compare July 29, 2026 22:17

marijamijailovic changed the base branch from main to next August 1, 2026 12:39

igamigo reviewed Aug 5, 2026

View reviewed changes

marijamijailovic added 8 commits August 11, 2026 00:01

Typed rendering for call output

4e9810c

cLi call-rename module,resolve procedure via manifest,debug types tests

ca9b4e1

feat(cli): render typed debug-info output in miden call

9bd3fc1

Drop the local package_debug_info module and consume the typed encoder/decoder from miden-mast-package's debug_info::typed instead.

feat(cli): read argument and result types from the package manifest

66e6418

Use miden-vm patch branch instead of a pinned rev

d1128b2

Fix lint check

744e6ec

fix(cli): restore the raw-felt fallback for procedures without a sign…

8c16f4a

…ature

fix(cli): adapt the typed call path to protocol rc.3 and miden-vm 0.29

988b6ff

marijamijailovic force-pushed the pr/call-typed-rendering branch from 7ebbf1f to 988b6ff Compare August 10, 2026 22:59

fix: restore code dropped during the rebase

c95500d

marijamijailovic force-pushed the pr/call-typed-rendering branch from 865bcd2 to c95500d Compare August 11, 2026 12:46

Uh oh!

Conversation

marijamijailovic commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marijamijailovic commented May 14, 2026

Uh oh!

igamigo commented May 15, 2026

Uh oh!

igamigo commented May 15, 2026

Uh oh!

marijamijailovic commented May 25, 2026

Uh oh!

Keinberger left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marijamijailovic commented Jun 1, 2026

Uh oh!

marijamijailovic commented Jun 4, 2026

Uh oh!

marijamijailovic commented Jun 9, 2026

Uh oh!

igamigo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marijamijailovic commented Jun 12, 2026

Uh oh!

igamigo commented Jun 12, 2026

Uh oh!

marijamijailovic commented Jun 18, 2026

Uh oh!

marijamijailovic commented Jun 20, 2026

Uh oh!

marijamijailovic commented Jun 20, 2026

Uh oh!

igamigo commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marijamijailovic commented Jun 23, 2026

Uh oh!

igamigo commented Jul 22, 2026

Uh oh!

marijamijailovic commented Jul 23, 2026

Uh oh!

bitwalker commented Jul 28, 2026

Uh oh!

igamigo left a comment

Choose a reason for hiding this comment

Uh oh!

igamigo Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

igamigo Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

marijamijailovic Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

igamigo Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

marijamijailovic Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

igamigo Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

marijamijailovic commented May 13, 2026 •

edited

Loading

Keinberger left a comment •

edited

Loading

igamigo commented Jun 22, 2026 •

edited

Loading